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1  Introduction 

Military  systems  are  often  safety  critical.  Errors  in  military  systems  may  even 
cause  our  own  military  casualties  and  civilian  life.  Recent  research  effort  on  mil¬ 
itary  planning  is  more  focusing  on  specifying  the  static  features  and  relations  in 
the  plan  ontology  [10, 16, 3].  However,  military  plans,  i.e.,  air  campaign  planning, 
have  additional  operations  and  timing  requirements.  For  example,  in  the  context 
of  a  plan  that  usually  consists  of  various  sub-plans,  we  may  need  to  specify  such 
scenarios:  plan  P  should  be  finished  within  T  time  units;  if  sub-plan  A  cannot 
be  completed  at  the  time  T,  then  stop  A  and  switch  to  sub-plan  B:  during  the 
execution  of  the  sub-plan  A,  if  an  emergent  event  E  happens  within  time  T.  then 
stop  A  and  switch  to  sub-plan  B.  It  is  desirable  to  not  only  formally  capture 
those  scenarios,  which  are  common  to  many  military  plans,  but  also  perform 
some  timed  plan  feasibility  analysis ,  i.e.,  checking  whether  it  is  possible  for  a 
plan  to  fulfil  some  requirements. 

In  this  project,  we  investigate  the  suitability  of  various  existing  real-timed 
formalisms  that  can  precisely  model  plans.  Timed  CSP  [13],  an  extension  of 
CSP  [5]  by  introducing  a  capability  to  quantify  temporal  aspects  of  sequencing 
and  synchronization,  is  chosen  as  the  modelling  language.  Timed  CSP  has  been 
widely  accepted  and  applied  to  a  wide  range  of  systems,  including  communication 
protocols,  embedded  systems,  etc  [14].  Timed  CSP  is  a  powerful  language  to 
model  real-time  reactive  system,  but  we  still  need  some  extra  critical  constraints 
on  the  system  which  the  traditional  Timed  CSP  language  is  not  capable  to  model, 
e.g.,  the  separation  time  between  two  events,  the  duration  of  a  sub-plan,  and 
etc.  We  extend  the  Timed  CSP  with  some  possible  features  to  complement  the 
language  in  precisely  modelling  the  timed  military  plans.  An  associated  tool  is 
needed  to  support  the  new  timed  plan  formalism.  Constraint  Logic  Programming 
(CLP  [7])  is  designed  for  mechanized  proving  based  on  constraint  solving.  CLP 
has  been  successfully  applied  to  model  programs  and  transition  systems  for  the 
purpose  of  verification  [9,4],  showing  that  their  approach  outperforms  the  well- 
know  state-of-art  systems  with  higher  efficiency.  In  this  work,  we  also  develop 
a  tool,  HORAE,  which  uses  the  CLP(R)  system  [8]  as  the  underlying  reasoning 
engine  and  is  implemented  in  JAVA.  HORAE  is  capable  to  specify  and  timed  plan 
feasibility  analyze  of  the  military  plans  modelled  in  this  timed  plan  formalism. 

The  remainder  of  this  report  is  organized  as  follows.  Section  2  briefly  intro¬ 
duces  Timed  CSP  and  Constraint  Logic  Programming.  Section3  illustrates  the 


reasoning  method  of  Timed  CSP  in  CLP.  We  mainly  focus  on  the  encoding  of 
operational  semantics  of  Timed  CSP.  Section  4  presents  the  extensions  of  the 
transitional  Timed  CSP  with  timed  planning  features  and  also  how  CLP  handles 
these  features.  Section  5  concludes  the  report. 


2  Background 

2.1  Timed  CSP 

Timed  CSP  [2]  extends  the  well-known  CSP  (Communicating  Sequential  Pro¬ 
cesses)  notation  of  Hoare  with  timing  primitives.  As  indicated  by  its  name, 
CSP  is  an  event  based  notation  primarily  aimed  at  describing  the  sequencing  of 
behaviour  within  a  process  and  the  synchronisation  of  behaviour  (or  communi¬ 
cation)  between  processes.  Timed  CSP  extends  CSP  by  introducing  a  capability 
to  consider  temporal  aspects  of  sequencing  and  synchronisation. 

CSP  adopts  a  symmetric  view  of  process  and  environment.  Events  represent 
a  co-operative  synchronisation  between  process  and  environment.  Both  process 
and  environment  may  control  the  behaviour  of  the  other  by  enabling  or  refusing 
certain  events  or  sequences  of  events. 


Process  Primitives  The  primary  building  blocks  for  Timed  CSP  processes  are 
sequencing,  parallel  composition,  and  choice. 

A  process  which  may  participate  in  event  a  then  act  according  to  process 
description  P  is  written 

a@t  — >  P(t). 

The  event  a  is  initially  enabled  by  the  process  and  occurs  as  soon  as  it  is  also 
enabled  by  its  environment.  The  event  a  is  sometimes  referred  to  as  the  guard 
of  the  process.  The  (optional)  timing  parameter,  t ,  records  the  time  (relative  to 
the  start  of  the  process)  at  which  the  event  a  occurs  and  allows  the  subsequent 
behaviour,  P ,  to  depend  on  its  value. 

The  second  form  of  sequencing  is  process  sequencing.  A  distinguished  event  / 
is  used  to  represent  and  detect  process  termination.  The  sequential  composition 
of  P  and  Q,  written  P;  Q ,  acts  as  P  until  P  terminates  by  communicating  / 
and  then  proceeds  to  act  as  Q.  The  termination  signal  is  hidden  from  the  process 
environment.  The  process  which  may  only  terminate  is  written  Skip. 

The  parallel  evolution  of  processes  P  and  Q ,  synchronised  on  event  set  X  is 
written 

P\[X]\Q. 


No  event  from  X  is  enabled  in  P  |[A]|  Q  unless  enabled  jointly  by  both  P  and 
Q.  Other  events  occur  in  either  P  or  Q  separately. 


Diversity  of  behaviour  is  introduced  through  two  choice  operators.  The  ex¬ 
ternal  choice  operator  allows  a  process  a  choice  of  behaviour  according  to  what 
events  are  enabled  by  its  environment.  The  process 

a  — y  P  n  b  — y  Q 

begins  with  both  a  and  b  enabled  and  performs  the  first  to  be  enabled  by  its 
environment.  Subsequent  behaviour  is  determined  by  the  event  which  actually 
occurred,  P  after  a  and  Q  after  b  respectively.  External  choice  may  also  be 
written  in  an  intentional  form, 

□  a  :  A  •  P(a). 

Internal  choice  represents  variation  in  behaviour  determined  by  the  internal  state 
of  the  process.  The  process 

a  — ^  P  n  b  — ^  Q 

may  initially  enable  either  a,  or  6,  or  both,  as  it  wishes,  but  must  act  subse¬ 
quently  according  to  which  event  actually  occurred.  Again  an  intentional  form 
is  allowed. 

An  derived  concept  in  CSP  is  the  notion  of  channel.  A  channel  is  a  collection 
of  events  of  the  form  c.n:  the  prefix  c  is  called  the  channel  name  and  the  collec¬ 
tion  of  suffixes  the  allowed  values  of  the  channel.  When  an  event  c.n  occurs  it 
is  said  that  the  value  n  is  communicated  on  channel  c.  By  convention,  when  the 
value  of  a  communication  on  a  channel  is  determined  by  the  environment  (exter¬ 
nal  choice)  it  is  called  an  input  and  when  it  is  determined  by  the  internal  state 
of  the  process  (internal  choice)  it  is  called  an  output.  It  is  convenient  to  write 
cln  :  N  —y  P(n)  to  describe  behaviour  over  a  range  of  allowed  inputs  instead 
of  the  longer  □  n  :  N  •  c.n  —y  P(n).  Similarly  the  notation  c\n  :  N  —y  P(n )  is 

used  instead  of  |~~1  n  :  N  •  c.n  —y  P(n)  to  represent  a  range  of  outputs.  Expres¬ 
sions  of  the  form  cln  and  c\n  do  not  represent  events,  the  actual  event  is  c.n  in 
both  cases. 

Recursion  is  used  to  given  finite  representations  of  non-terminating  processes. 
The  process  expression 

fi  P  •  aln  —y  b\f(n)  —y  P 

describes  a  process  which  repeatedly  inputs  an  integer  on  channel  a,  calculated 
some  function  /  of  the  input,  and  then  outputs  the  result  on  channel  b.  CSP 
specifications  are  typically  written  as  a  sequence  of  simultaneous  equations  in  a 
finite  collection  of  process  variables.  Such  a  specification  X  ==  F(X)  is  implic¬ 
itly  taken  to  describe  the  solution  to  the  vector  recursion  pX  •  F(X). 

In  general,  the  behaviour  of  a  process  at  any  point  in  time  may  be  dependent 
on  its  internal  state  and  this  may  conceivably  take  an  infinite  range  of  values.  It 
is  often  not  possible  to  provide  a  finite  representation  of  a  process  without  intro¬ 
ducing  some  notation  for  representing  this  internal  process  state.  The  approach 


adopted  by  CSP  is  to  allow  a  process  definition  to  be  intentionally  parameterised 
by  state  variables.  Thus  a  definition  of  the  form 

Pn:N  =  Q{n) 

represents  a  (possibly  infinite)  family  of  definitions,  one  for  each  possible  value 
of  n.  It  is  important  to  note  that  there  is  no  inherent  notion  of  process  state  in 
CSP,  but  rather  that  this  intentional  form  of  expression  is  a  convenient  way  to 
provide  a  finite  representation  of  an  infinite  family  of  process  descriptions. 


Timing  Primitives  To  the  standard  CSP  process  primitives,  Timed  CSP  adds 
two  time  specific  primitives,  the  delay  and  the  timeout. 

A  process  which  allows  no  communications  for  period  t  then  terminates  is 
written  Wait  t.  The  process 

Wait  t-,  P 

is  used  to  represent  P  delayed  by  time  t.  A  process  e  A  P  delays  process  P  by 
t  time  units  after  engaging  event  e. 

The  timeout  construct  passes  control  to  an  exception  handler  if  no  event  has 
occurred  in  the  primary  process  by  some  deadline.  The  process 

a  — y  P  [>{£)■  Q 

will  pass  control  to  Q  if  the  a  event  has  not  occurred  by  time  t,  as  measured 
from  the  invocation  of  the  process. 

Example  1  (Air  Campaign  Mission).  We  are  planning  an  air  attack  mission  to 
destroy  the  military  force  of  a  designated  area  where  most  of  the  military  forces 
of  the  enemy  are  centralized.  This  mission  is  consists  of  three  sub  tasks.  Task  A, 
namely  Bomb ,  is  to  destroy  the  radar  of  the  enemy.  Task  B  is  the  main  attack, 
where  a  team  of  ground-attack  aircrafts  will  fly  to  the  specific  area  and  give 
a  fierce  attack  to  the  targeted  military  bases.  If  this  task  cannot  be  completed 
within  60  minutes,  then  it  will  switch  to  task  C  which  is  sending  the  air  reinforce 
to  the  main  air  attack. 

5  io 

Bomb  =  assemble  — »  equipment  — >  advance  — >  lunchMissile  — >  retreat  —>  SKIP 

5  .  5 

AirAttack  =  assemble  equipment  — >  advance  — >  arrive  — >  attack  — >  SKIP-, 

( victory  — »  retreat  — >■  SKIP )  n  ( lose  — »  retreat  —>  SKIP) 

5 

Reinforce  =  assemble  — ►  equipment  — >  advance  supporting -attack  — >  SKIP-, 
( victory  —>  retreat  — >  SKIP)  n  ( lose  retreat  — >  SKIP) 

Mission  =  Bomb-,  ( AirAttack  Ago  Reinforce) 


2.2  CLP  Preliminaries 

Constraint  Logic  Programming  (CLP)  began  as  a  natural  merger  of  two  declar¬ 
ative  paradigms:  constraint  solving  and  logic  programming.  This  combination 


helps  make  CLP  programs  both  expressive  and  flexible,  and  in  some  cases,  more 
efficient  than  other  kinds  of  programs.  The  CLP  scheme  defines  a  class  of  lan¬ 
guages  based  upon  the  paradigm  of  rule-based  constraint  programming,  where 
CLP  (77)  is  an  instance  of  this  class.  We  present  some  preliminary  definitions 
about  CLP  [7]. 

Example  2  (Factorial).  The  following  is  typical  CLP  program: 

/ac(0, 1). 

fac(N,  X\  *  N)  :  -N  >  0,fac(N  -  1,  Xj). 

A  relation  fac(N,  X)  is  defined,  where  X  is  the  factorial  of  N ,  denoted  as  X  =  N\. 
There  are  two  atoms  for  the  relation  fac(N,  X),  where  the  first  atom  is  a  fact 
and  the  second  one  is  a  rule. 

The  universe  of  discourse  V  of  our  CLP  program  is  a  set  of  terms,  integers, 
and  lists  of  integers.  A  Constraint  is  written  using  a  language  of  functions  and 
relations.  They  are  used  in  two  ways,  in  the  basic  programming  language  to 
describe  expressions  and  conditions,  and  in  user  assertions,  defined  below.  In  this 
paper,  we  will  not  define  the  constraint  language  explicitly,  but  invent  them  on 
demand  in  accordance  with  our  examples.  Thus  the  terms  of  our  CLP  programs 
include  the  function  symbols  of  the  constraint  language. 

An  atom ,  is  as  usual,  of  the  form  p(t),  where  p  is  a  user  defined  predicate 
symbol  and  t  is  a  sequence  of  terms.  A  rule  is  of  the  form  A  :  —B,P  where  the 
atom  A  is  the  head  of  the  rule,  and  the  sequence  of  atoms  B  and  the  constraint 
P  constitute  the  body  of  the  rule.  A  goal  has  exactly  the  same  format  as  the  body 
of  the  rule  of  the  form  ?  —  B,P.  If  B  is  an  empty  sequence  of  atoms,  we  call 
this  a  (constrained)  fact.  All  goals,  rules  and  facts  are  terms.  A  ground  instance 
of  a  constraint,  atom  and  rule  is  defined  in  obvious  way.  A  ground  instance  of 
a  constraint  is  obtained  by  instantiating  variables  therein  from  V.  The  ground 
instances  of  a  goal  G,  written  [G]  is  the  set  of  ground  atoms  obtained  by  taking 
all  the  true  ground  instances  of  G  and  then  assembling  the  ground  atoms  therein 
into  a  set.  We  write  Gi  |=  G2  to  mean  that  for  all  groundings  9  of  G\  and  G2, 
each  ground  atom  in  G\6  appears  in  G2O. 

Let  G  =  (Bi, ...,  Bn,  P)  and  P  denote  a  goal  and  program  respectively.  Let 
R  =  A  :  —  Gi, ...,  Gm ,  P\  denote  a  rule  in  P,  written  so  as  none  of  its  variables 
appear  in  G.  Let  A  =  B,  where  A  and  B  are  atoms,  be  shorthand  for  equations 
between  their  corresponding  arguments.  A  reduct  of  G  using  R  is  of  the  form 

(Bi,  •••,  Ci, ...,  Cm,  Bi+ 1, ...,  Bn,  Bi  =  A  A  P  A  Sfi) 

provided  5*  =  A  A  P  A  P\  is  satisfiable.  A  derivation  sequence  is  a  possibly 
infinite  sequence  of  goals  Go,  Gi, ...  where  Gl ,  *  >  0  is  a  reduct  of  Gt _  1 .  If  there 
is  a  last  goal  Gn  with  no  atoms,  notationally  (□,<?)  and  called  a  terminal  goal , 
we  say  that  the  derivation  is  a  successful  and  that  the  answer  constraint  is  P. 
A  derivation  is  ground  if  every  reduction  therein  is  ground. 


Example  3  (Derivation).  We  calculate  the  3!  through  the  goal  ?  —  fac( 3,  X). 
The  following  demonstrates  a  derivation  sequence  of  the  goal  with  three  steps. 
The  constraints  in  the  last  step  which  are  the  termination  goal  answer  X  =  6. 


N  =  3,  fac(N ,  X). 

N  =  3,N  >0,N  -l=Nx,X  =N *  X1,fac(N1,X1). 

IV  =  3,  N  >  0,  N  —  1  =  N±,  X  =  N  * 

W  >  0,  W  -  1  =  N2,  X1  =  Nx*  X2Jac(N2 ,  X2). 

N  =  3,  N  >  0,  N  —  1  =  Ni,  X  =  N  *  X±,  Ni  >  0,  N±  —  1  =  N2, 
XI  =  Ni  *  X2,  A2  >  0,  N2  -  1  =  0,  X2  =  1. 


3  Reasoning  Method  for  Timed  CSP 

3.1  Timed  CSP  Semantics  in  CLP 

This  section  is  devoted  to  an  encoding  of  the  semantics  of  Timed  CSP  in  CLP. 
The  practical  implication  is  that  we  may  then  use  powerful  constraint  solver 
like  CLP(R)  [8]  to  do  various  proving  over  systems  modelled  using  Timed  CSP. 
Both  the  operational  semantics  and  denotational  semantics  are  encoded.  The 
encoding  of  operational  semantics  serves  most  of  our  purposes.  Nevertheless 
the  encoding  of  the  denotational  semantics  offers  an  alternative  way  of  proving 
systems  modelled  in  Timed  CSP  as  well  as  the  correctness  of  the  encoding  itself. 

The  very  initial  step  of  our  work  is  the  syntax  encoding  of  Timed  CSP  process 
in  CLP  syntax,  which  can  be  automated  easily  by  syntax  rewriting.  A  relation  of 
the  form  proc(N ,  P )  is  used  to  present  a  process  P  with  name  N.  For  instance, 
Figure  1  is  the  syntax  encoding  of  process  Military  Mission  Plan  in  CLP,  which 
is  a  timed  interrupt  process  with  name  mission. 

3.2  Operational  Semantics 

The  operational  semantics  of  Timed  CSP  is  precisely  defined  by  Schneider  [15] 
using  two  relations:  an  evolution  relation  and  a  timed  event  transition  relation.  It 
is  straightforward  to  verify  that  our  encoding  conforms  the  two  relations  in  [15]. 

A  relation  of  the  form  tos(Pl,Tl,E,P2,T2)  is  used  to  denote  the  timed 
operational  semantics,  by  capturing  both  evolution  relations  and  timed  event 
transition  relations.  Informally  speaking,  tos(Pl,Tl,E,P2,T2)  is  true  if  the  pro¬ 
cess  PI  may  evolve  to  P2  through  either  a  timed  transition,  i.e.,  let  T2-T1  time 
units  pass,  or  an  event  transition  by  engaging  an  abstract  event  instantly1.  The 
relation  tos  defines  a  transition  system  interpretation  of  a  Timed  CSP  process, 

1  Or  both  at  the  same  time  by  engaging  an  nontrivial  action  which  takes  time  (neces¬ 
sary  for  only  extensions  to  Timed  CSP  like  TCOZ  [11]  where  E  could  be  a  compli¬ 
cated  computation) 


proc(mission,  sequence  (PI,  P  2))  :  —proc(bomb,  PI),  proc(attack,  P2). 
proc(attack,  tinterrupt(P  1,  P 2,  60))  :  — proc(mainattack ,  PI),  proc(reinforce,  P 2). 
proc(bomb,  eventprefix(assemble,  eventprefix (equipment,  P)))  :  —proc(bomb  1,  P). 
proc(bomb  1,  delay  (advance,  delay  (lunchMissile,  eventprefix  (retreat,  skip),  10),  5)). 
proc(mainattack ,  sequential  (PI,  P  2))  :  —  procfmal,  PI),  proc(ma2,  P  2). 
proc(ma  1,  eventprefix(assemble,  eventprefix(equipment,  P)))  :  —proc(ma  11,  P). 
proc(mall,  delay  (advance,  delay(arrive,  eventprefix  (attack,  skip),  5),  5). 
proc(ma2,  intchoice(Pl,  P2))  :  —  proc(ma21,  PI),  proc(ma22,  P2). 
proc(ma  21,  eventprefix(vicotry ,  eventprefix  (retreat,  skip))). 
proc(ma22,  eventprefix(lose,  eventprefix  (retreat,  skip))). 
proc(reinforce ,  sequential(Pl,  P 2))  :  —proc(rf  1,  PI),  proc(rf2,  P 2). 
proc(rf  1,  eventprefix(assemble,  eventprefix(equipment,  P)))  :  —proc(rf  11,  P). 
proc(r,/ll,  delay  (advance,  eventprefix(supportingattack,  skip),  5)). 
proc(rf2,intchoice(Pl,P2))  :  —proc(rf  21,  PI),  proc(rf  22,  P2). 
proc(rf  21,  eventprefix(vicotry ,  eventprefix  (retreat,  skip))). 
proc(rf22,  eventprefix(lose,  eventprefix  (retreat,  skip))). 


Fig.  1.  Military  Mission  Planning  in  CLP 


where  the  state  is  identified  by  the  combination  of  the  process  expression  and  the 
time  variable.  Using  tabling  mechanism  offered  in  some  of  the  constraint  solvers 
like  CLP(77)  [8]  or  XSB  [17],  the  termination  of  the  derivation  sequence  based 
on  relation  tos  depends  on  the  finiteness  of  the  reachable  process  expressions 
from  the  initial  one.  Therefore,  if  a  process  is  irregular  (i.e.  its  trace  is  irregular 
as  in  automata  theory),  proving  of  goals  which  need  to  explore  all  reachable  pro¬ 
cess  expressions  is  not  feasible.  However,  even  for  irregular  processes,  interesting 
proving  like  existence  of  a  trace  is  still  possible. 

We  define  the  tos  relation  in  terms  of  each  and  every  operator  of  Timed  CSP. 
For  the  moment,  we  assume  the  process  is  not  parameterized  and  we  shall  han¬ 
dle  parameterized  processes  uniformly  in  Section  4.  For  instance,  the  primitive 
process  expressions  in  Timed  CSP  are  defined  through  the  following  clauses: 

tos(stop,  T 1,  [],  stop,  T2)  :  —D  >=  0,  T2  =  T1  +  D. 

tos(skip,  T,  [termination],  stop,  T). 

tos(skip,  Tl,  [],  skip,  T2)  :  —  D  >=  0,  T2  =  T1  +  D. 

tos(run,  T,  [_],  run,  T). 

tos(run,  Tl,  [],  run,  T2)  :  —  D  >=  0,  T2  =  Tl  +  D. 

The  only  transition  for  process  Stop  is  time  elapsing.  Process  Skip  may 
choose  to  wait  some  time  before  engaging  event  termination  which  is  our  choice 
of  representation  for  event  /  in  CLP.  Process  Run  may  either  let  time  pass 
or  engage  any  event.  In  the  following,  we  show  how  hierarchical  operators  are 
encoded  in  CLP  using  the  alphabetized  parallel  composition  operator  as  an 
example. 


In  the  operational  semantics,  the  event  transition  and  evolution  transition 
associated  with  the  alphabetized  parallel  composition  operator  the  alphabetized 
parallel  composition  operator  Pi  x\\y  Pi  are  illustrated  as  the  following  [15]: 


Pi  4p[ 

Pi  x\\y  P2  4  P{  x  1 1  y  P2 


e£lU  {r}  \  Y  ] 


P2  4  p'2 

Pi  x\\y  P2  4  Pi  X  | J Y  P'l 


e  e  FU{r}\X] 


Pi  4  p[,p2A  p' 

■Pi  x  1 1  y  P2  4  P[  x  1 1  y  P2 

Pr  4  p[,p2  4p' 

Pi  x  ||  y  P2-P^  x  ||  y  P2 

The  — ►  represents  an  event  transition,  whereas  represents  an  evolution 
transition.  The  rules  associated  with  the  alphabetized  parallel  composition  op¬ 
erator  are  as  the  following: 

tos(para(Pl,  P2,  X,  F),  T,  [E],para{P3,P2,X,  Y),  T ) 

:  —  tos(Pl,  T,  [E],P3,  T) ,  member  (E,X),  not  {member  (E,  F)). 
tos(para(Pl,  P2,  X,  Y),  T,[E],para{Pl,  PA,X,  F),  T ) 

:  —tos(P2,  T,  [P],P4,  T),  member (E,  Y),not(member(E,X)). 
tos(para(Pl,  P2,  X,  Y),  T,[E],para{P3,  P4,X,  F),  T) 

:  -tos(Pl,  T,  E,  P3,  T),  tos(P2,  T,  E,  P4,  T), 
member (E,  X),  member (E,  Y). 
tos{para{P  1,  P2,  X,  F),  PI,  0,  para(P3,  P4,  X,  F),  PI  +  £>) 

:  -tos(Pl,  PI,  [],  P3,  PI  +  D),  tos(P2,  P1,[],P4,  Pl  +  P). 

The  first  two  rules  state  that  either  of  the  components  may  engage  an  event 
as  long  as  the  event  is  not  shared.  The  third  rule  states  that  a  shared  event 
can  only  be  engaged  simultaneously  by  both  components.  The  last  expresses 
that  the  composition  may  allow  time  elapsing  as  long  as  both  the  components 
do.  Other  parallel  composition  operation,  like  |  [  X  ]  \  and  1 1 1 ,  can  be  defined  as 
special  cases  of  the  alphabetized  parallel  composition  operator  straightforwardly. 
There  is  a  clear  one-to-one  correspondence  between  our  rules  and  the  operators 
which  are  partly  illustrated  in  Appendix  A  and  fully  at  our  website2.  Therefore, 
the  soundness  of  the  encoding  can  be  proved  by  showing  there  is  a  bi-simulation 
relationship  [12]  between  the  transition  system  interpretation  defined  in  [15]  and 
ours,  and  the  bi-simulation  relationship  can  be  proved  easily  via  a  structural 
induction. 
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For  simplicity,  we  do  restrict  the  form  of  recursion  to  ynX  •  P(X),  which 
means  mutual  recursion  through  process  referencing  has  to  be  transformed  before 
hand.  The  following  clauses  illustrate  how  recursion  is  handled,  where  N  is  the 
recursion  point,  i.e.,  X  in  /./,  X  •  P ( X ) )  and  P  is  the  process  expression,  i.e., 
P(X). 

tos(recursion([N ,  P],  PI),  T ,[E],  recursion([N ,  P],  P2),  T) 

:  -not(Pl  ==  N),  tos(Pl,  T,  [E],  P2,  T). 
tos(recursion([N ,  P],  PI),  Tl,  [],  recursion([N ,  P],  P2),  Tl  +  D) 

:  —D  >  0,  tos(Pl,  Tl,  [],  P2,  T\  +  D). 
tos(recursion([N ,  P],  N),  T ,  [],  recur sion([N ,  P],  P),  T). 


3.3  Proving  Properties  of  Timed  CSP 

This  section  is  devoted  to  various  proving  we  may  perform  over  systems  modelled 
using  Timed  CSP  and  then  encoded  in  CLP.  We  implemented  a  prototype  in  one 
of  the  CLP  solver,  namely  CLP(7£).  Any  CLP  assertion  can  be  proved  against 
a  given  real-time  system.  We  also  developed  a  number  of  shortcuts  for  easy 
querying  and  proving. 

Using  CLP,  we  may  make  explicit  assertion  which  is  neither  just  a  safety 
assertion,  nor  just  a  liveness  assertion.  Yet  it  can  be  used  for  both  purposes 
using  a  unique  interpretation.  In  the  following,  we  show  how  safety  properties 
and  liveness  properties,  like  reachability,  can  be  queried.  We  employ  the  concept 
of  coinductive  tabling  with  the  purpose  of  obtain  termination  when  dealing  with 
recursions,  which  facilitates  verifying  safety  and  liveness  properties  based  on 
traces.  The  detailed  introduction  of  coinductive  tabling  can  be  found  in  [6] . 

Because  Timed  CSP  is  an  event-based  specification  language,  it  is  clearly 
useful  to  prove  safety  and  liveness  properties  in  terms  of  predicate  concerning 
not  only  state  variables  but  also  events.  A  discussion  on  how  to  allow  such 
temporal  properties  is  presented  in  [1].  In  order  to  explore  the  full  state  space, 
we  define  the  following3: 

treachable(P ,  P,  (],  Tl,  Tl). 

treachable(P ,  Q,  N,  Tl,  T2)  :  —  tos(P,  Tl,  [tau],  PI,  T3),  nottable(Pl) , 
assert  (table  (Pl)),treachable  (PI,  Q,N,  T3,  T2). 

treachable(P ,  Q,  [f(T>)  |  N],  Tl,  T2)  :  -tos(P,  Tl,  [t(D)\,  PI,  T3), 
nottable(Pl),  assert(table(Pl)) , 
treachable(Pl,  Q,N ,  T3,  T2),  notN  =  [f(_)  |j  . 

treachable(P ,  Q,  [E  \  N],  Tl,  T2)  :  -tos(P,  Tl,  [ E ],  PI,  T3), 

not(E  =  <(_);  E  ==  tau ;  E  =  reccall(X)) ,  nottable(Pl), 
assert  (table  (PI)),  treachable(Pl,  Q,N ,  T3,  T2). 

The  relation  treachable(P,  Q,  N,  Tl,  T2)  states  that  it  is  possible  to  reach 
the  process  expression  Q  at  time  T2  from  P  at  time  Tl,  with  trace  N.  where  tau 
is  the  internal  event  r  and  t(  )  denotes  the  time  elapsing.  By  using  the  tabling 

3  The  possible  state  variables  and  local  clocks  are  skipped  for  simplicity. 


method,  we  dynamically  record  the  process  expressions  that  have  been  explored 
so  as  to  avoid  re-exploring  them.  In  this  regard,  one  kind  of  liveness  property 
namely  reachability  is  easily  asserted  using  treachable. 

An  invariant  property  (a  predicate  over  time  variable  and  state  variables  and 
possible  local  clocks)  is  in  general  expressed  as  the  assertion: 

inv(P,  T ,  Property)  :  —  not  (treachable  (P ,  Q,~,  T,  Tl),not  sat  (Property)). 

where  not  sat  (Property)  is  a  constraint  indicating  that  the  output  from  the 
previous  atom  not  satisfying  the  user  defined  Property. 

One  safety  property  of  special  interest  is  deadlock-freeness.  The  following 
clauses  are  used  to  prove  it. 

deadlock(P,  T1,N)  :  —treachable(P,  PI,  N ,  T 1,  T2), 

(tos(P  1,  T2,  [f  (_)],  Ql,  T3)  — >  not(tos(Q  1,  T3,  E,  _,  _),  not  E  =  [£(_)]); 

not(tos(P  1,  T2,  E,  Ql,  T3),  notE  =  [f (_)])), 
printf  (”  deadlock  at  trace  :  %\n” ,  [IV]). 

Basically,  it  states  that  a  process  P  at  time  T1  may  result  in  deadlock  if  it  can 
reach  the  process  expression  PI  at  time  T2  where  no  event  transition  is  available 
neither  at  T2  nor  at  any  later  moment.  The  last  line  outputs  the  deadlocked  trace 
as  a  counterexample.  Alternatively,  we  may  present  it  as  a  result  of  the  deadlock 
proving. 

We  allow  trace-based  properties  (safety  or  liveness)  that  can  be  checked  by 
exploring  trace  set  partially.  The  retrieve  of  a  trace  is  done  by  the  predicate 
superstep(P ,  N,  Q),  which  finds  a  sequence  of  events  through  which  process  ex¬ 
pression  P  evolves  to  Q: 

superstep(P ,  [_], _)  :  —not(tos(P,-,-,Q,J),not  table(Q)). 

superstep(P ,[A  |  IV],  Q)  :  —  tos(P,-,M,Pl,J),not(M  ==  [];  M  ==  [taw]), 

M  =  [A],  not  table(Pl),  assert (table(Pl)),  superstep(Pl,  N ,  Q). 
superstep(P ,  N ,  Q)  :  —  tos(P,-,M,Pl,_),(M  ==  [];  M  ==  [ tau ]), 
not  table(Pl),  assert (table(Pl)) ,  superstep(P  1,  N,  Q). 

We  may  prove  that  some  event  will  always  eventually  be  ready  to  be  en¬ 
gaged  using  the  following  rule:  where  rule  member (E,  N)  returns  true  if  event 
E  appears  at  least  once  in  the  event  sequence  N. 

finally (P,E)  :  —not(superstep(P,N,J),not  member (E ,  N)). 

Predicate  finally(P,  E)  captures  the  idea  that  there  is  no  such  trace  without 
event  E  in  this  process  P.  In  other  words,  this  process  will  eventually  go  to 
event  E.  Another  property  based  on  traces  would  be  identifying  the  relationship 
among  events,  e.g.,  event  A  can  never  happen  before  (after)  event  B  in  a  trace 
or  trace  fragment. 

Example  4  (Verification) .  For  the  military  mission  example,  we  can  verity  that 
it  is  not  possible  that  at  the  end  of  this  mission,  the  army  is  neither  win  or  lose, 


by  executing  the  following  goal,  which  returns  false. 

?  —  proc(mission,  P),  superstep(P,  N ,  stop), 
not  (member  (win,  N);  member  (lose,  N)). 

In  reality,  most  processes  are  non-terminating,  so  it  would  not  be  possible 
to  retrieve  all  possible  traces  of  a  process.  However,  by  given  a  specific  trace  of 
a  trace  fragment,  we  are  able  to  identify  whether  it  is  an  event  sequencing  of  a 
given  process.  For  instance,  the  following  clause  is  used  to  query  if  a  sequence 
of  event  is  a  trace  of  the  system,  where  P  is  a  process  expression  and  X  is  a 
sequence  of  events. 

trace(P,  X)  :  —  super  step  (P ,  X ,)  . 

In  addition  to  proving  pre-specified  assertions,  one  distinguished  feature  of  our 
approach  is  that  implicit  assertions  may  be  proved.  For  example,  we  may  identify 
the  lower  or  upper  bound  of  a  (time  or  data)  variable,  which  is  very  useful  for 
applications  like  worst  or  best  case  analysis  of  execution  time. 

dur(P,  Q,  Tl,  T2)  :  -tos(P,  Tl,  ,  Q,  T2). 

dur(P,  Q,  Tl,  T2)  :  -tos(P,  Tl,  ,  PI,  T3),  dur(Pl,  Q,  T3,  T2). 

We  are  able  to  compute  the  duration  of  the  execution  of  one  process  P  to  its 
subsequent  process  Q  by  the  above  two  rules,  where  T\  is  the  starting  time  and 
T2  is  the  ending  time.  By  using  the  predicate  dur,  we  are  able  to  get  identify  the 
lower  bound  of  some  processes  involving  time.  The  process  Wait(2);  a  — »  Skip 
should  terminate  in  more  than  5  time  units,  which  can  be  identified  by  the 
following  goal  and  expecting  T>5. 

?  —  dur  (sequential  (wait  ( 2),  delay  (a,  skip,  3)),  stop,  0,  T). 


3.4  Improvement  of  the  Reasoning  Engine 

The  execution  time  and  state  space  of  reasoning  properties  of  a  Timed  CSP 
system  mainly  lie  on  the  number  of  events  of  the  system.  Generally  speaking, 
the  more  events  in  a  system,  the  more  state  space  and  execution  time  it  takes. 

We  make  some  abstraction  on  the  existing  Timed  CSP  system  by  eliminating 
some  events  according  to  the  property  we  want  to  check,  without  affecting  the 
semantics  of  the  system  related  to  this  property.  For  the  deadlock  property,  we 
can  eliminate  all  the  events  which  are  not  in  the  parallel  interfaces  and  also  not 
the  control  events  (i.e.,  not  the  first  event  of  the  interrupt  process). 

Pl  =  a->64c->rf->Pl 

P2  =  e4(l)4c->P2)n(c->  P2) 

P  =  Pl\[b,c]\P2 


To  check  the  property:  deadlock (P),  we  simply  the  process  P  to  P'  by  eliminating 
event  a, and  e  . 

PI  =  b  4  c  ->  PI 

P2  =  WAIT(1)-,  (b  4  c  -A  P2)  □  (c  ->  P2) 

P'  =  Pl\[b,c]\P2 

^From  P'  we  can  easily  check  that  P  is  a  deadlock  free  process. 

4  Timed  CSP  with  Timed  Planning 

As  exemplified  in  the  previous  sections,  Timed  CSP  captures  a  large  set  of 
behavior  patterns  in  military  planning.  There  are,  however,  relatively  few  design- 
independent  planning  requirements.  For  instance,  a  quick  attack  must  finish 
in  a  few  days,  the  number  of  loadings  must  be  greater  than  the  number  of 
firings  for  any  weapon,  etc.  In  other  words,  there  might  be  process  independent 
system  constraints  which  have  to  be  enforced.  Any  successful  planning  must  take 
these  constraints  into  consideration.  Thus,  we  extend  the  existing  Timed  CSP  by 
adding  a  where  clause  to  specify  such  constraints.  Using  the  constraint  solver, 
we  can  not  only  tell  if  planning  is  possible  but  also  automatically  generate  a 
feasible  plan,  if  there  is  any. 


4.1  Syntax 

Each  process  is  extended  with  an  optional  where  clause,  which  consists  of  a 
(first  order)  predicate  over  a  predefined  set  of  time  variables.  For  instance,  given 
a  process  P,  the  variable  P. start  (P.end)  denotes  the  exact  starting  (ending) 
time  of  the  process.  More  specifically,  P. start  captures  the  starting  time  of  P 
when  its  first  event  is  enabled  or  when  the  Wait  d  process  is  enabled  if  P  starts 
with  the  Wait  process.  P.end  captures  the  ending  time  of  P  which  is  the  same 
as  the  occurrent  time  of  the  termination  event  / .  Naturally,  P.end  >  P. start 
all  the  time.  Using  the  two  variables,  a  deadline  property  (a  task  must  be  ac¬ 
complished  within  certain  time)  is  expressed  as  P  where  P.end  —  P. start  <  d 
where  d  is  constant.  In  other  scenarios,  there  may  be  a  requirement  on  some 
event  to  occur  at  some  exact  time,  e.g.,  the  marching  of  the  troops  must  begin 
after  half  an  hour  and  no  later  than  one  hour  of  the  air  force  bombing.  A  time 
variable  engage  may  be  attached  to  an  event  to  denote  the  exact  time  when  e 
is  engaged. 

Example  5.  The  following  example  illustrates  the  use  of  the  time  variables, 

Task  =  Bombing ;  march  — »  Sweeping 

where  Bombing,  end  —  Bombing  .start  <  172800  A 
Bombing. end  +  3600  >  march. engage  >  Bombing. end  +  1800 

The  bombing  finishes  in  two  days  and  the  marching  must  start  half  an  hour  after 
the  bombing  stops  (so  as  to  secure  the  ground  before  enemy  returns).  □ 


In  addition,  we  use  the  variable  P.tr  where  P  is  an  optional  process  to  denote 
an  arbitrary  trace  of  process  P.  If  P  is  missing,  it  is  default  as  the  process  name 
on  the  left  hand  side. 

Example  6.  The  following  example  illustrates  a  constraint  using  the  variable  tr. 
Assume  that  a  gunboat  is  equipped  with  two  canons.  There  are  two  soldiers,  one 
in  charge  of  loading  shells  (one  of  the  canon  at  a  time)  and  the  other  firing  (one 
of  the  canon  at  a  time). 

Loading  —  load\  — >  Loading  □  load2  — >  Loading 

Firing  =  aim\  — ►  fire i  — >  Firing  □  aim2  — »  fire 2  Firing 

Gunboat  =  Loading  ||  Firing 

where  tr  4,  load\  >  fire  1  A  tr  l  loadk  >  fire 2 

where  tr  f  e  denotes  the  number  of  occurrences  of  event  e  in  the  trace  tr.  We 
remark  that  e  must  be  in  the  alphabet  of  the  process.  □ 

In  the  following,  we  define  the  syntax  of  the  where  clause. 

CP  ::=  P  where  WherePred 


WherePred  ::=  WherePre  A  WherePred 
j  WherePre  V  WherePred 
|  WherePre  -w-  WherePred 
i  WherePre  =>■  WherePred 
|  1  WherePre  \  true  \  false 

|  WhereExpr 


WhereExpr 


[Name.]  start 
[IVome.]END 
[Name.  ]ENGAGEj 
[Name.]  tr 

WhereExpr  Infix  WhereExp 
Prefix  Exp  \  Name  \  ( WhereExp ) 


-  start  time  of  a  process 

-  end  time  of  a  process 
-the  ith  engage  time  of  e 

-  trace  of  P 


This  syntax  does  not  define  the  details  of  the  Infix,  Prefix,  PostFix,  Name.  A 
name  is  a  sequence  of  characters  starting  an  alphabet.  Typical  infix  operators 
are  {+,-,>,<}  or  tr  4-  e  which  is  the  number  of  e  in  the  trace.  An  example  prefix 
operator  is  #tr  which  denotes  the  length  of  the  trace.  Notice  that  P. start  < 
e. ENABLEj  <  e. ENGAGE}  <  P.end).  For  each  event  e  in  process  P ,  its  enable 
time  must  be  smaller  than  its  engaged  time,  while  the  start  time  of  P  must  be 
smaller  than  the  enabled  time  of  e  and  the  end  time  of  P  must  be  greater  than 
the  engaged  time  of  e. 

Example  7.  The  following  demonstrates  that  sing  the  basic  terms  and  constraint 
defined  above,  common  planning  requirements  can  be  specified  rather  easily. 


T.end  <  d 


Task  T  must  finish  before  time  d. 


e. ENGAGE.,  -  e. ENGAGE,  >  tl  A  j  >  1 
Minimum  separation  between  two  appearances  of  e  is  tl. 

e. ENGAGE.,  -  e. ENGAGE,  <  t2  A  j  =  i  +  1 
Maximum  separation  between  two  appearances  of  e  is  t2.  □ 

Because  the  where  clause  attached  to  a  process  definition  is  local  to  the 
process,  only  events,  processes  and  variables  visible  to  the  process  may  appear 
in  the  clause.  This  is  by  no  means  a  restriction,  instead,  it  allows  a  modular 
specification  of  planning  constraints.  Semantically,  the  where  clause  restricts 
the  set  of  traces  allowed  by  the  process.  Informally,  the  process  serves  as  a 
possible  implementation  of  the  plan,  whereas  the  where  clause  is  the  high-level 
requirements  (that  must  be  guaranteed  for  any  implementation  of  the  plan).  For 
instance,  is  a  local  constraint  on  P  which  would  only  affect  the  behaviors  of  P. 

If  P  is  a  sub- process  of  Q,  the  rest  processes  of  Q  are  affected  by  the  constraint 
if  and  only  if  there  are  synchronization  events  between  P  and  the  rest  of  Q. 
Otherwise  the  other  processes  in  Q  would  not  be  affected  even  though  they  also 
contain  the  events  appear  in  the  constraint.  In  contrast,  all  sub-processes  of  Q 
must  satisfy  the  constraint  on  Q.  In  other  words,  P  is  constrained  by  its  local 
constraint  and  the  constraints  of  Q. 

Example  8.  The  Military  Mission  Planning  example  defined  in  1,  some  feasible 
time  planning  requirements  can  be  added.  For  example,  the  Bomb  task  it  a  rapid 
attack,  which  should  be  finished  within  30  minutes,  the  main  attack  fighters 
must  arrive  at  the  destination  area  in  10  minutes.  Whenever  the  reinforce  army 
receives  the  command  from  the  headquarter  to  go  to  the  war,  it  should  take  at 
most  15  minutes  for  its  equipping  and  march  till  they  start  to  attack.  Moreover, 
the  whole  mission  must  be  finished  within  150  minutes. 

5  io 

Bomb  =  assemble  — »  equipment  — >  advance  — »  lunchMissile  — >  retreat  — >  SKIP 
where  Bomb. end  -  Bomb. start  ^  30 

Air  Attack  =  assemble  -A  equipment  — »  advance  — >  arrive  attack  — >  SKIP-, 

( victory  — >  retreat  — >  SKIP )  n  ( lose  — >  retreat  — >  SKIP ) 
where  arrive. engage  —  advance. engage  ^  10 

5 

Reinforce  =  assemble  — ►  equipment  — >  advance  supporting -attack  — >  SKIP-, 

( victory  —>  retreat  — >  SKIP )  n  ( lose  retreat  — >  SKIP ) 

where  supporting -attack,  eng  age  —  assemble,  engage  ^  15 
Mission  =  Bomb ;  ( AirAttack  Ago  Reinforce ) 

where  Mission. end  —  Mission. start  ^  150 


4.2  Timed  Planning  in  CLP(R) 

A  military  plan  documented  using  the  extended  Timed  CSP  might  not  be  fea¬ 
sible.  For  instance,  P  =  load  aim  —>  fire  P  where  fire. engage,  — 


load. engage,  <  4  is  an  inconsistent  plan.  This  boils  down  to  the  critical  ques¬ 
tion  that  how  effective  we  can  verify  if  a  plan  is  feasible.  In  this  section,  we  show 
that  using  CLP(R),  we  can  not  only  do  that  but  also  automatically  synthesize 
a  schedule  of  the  plan,  if  it  is  feasible. 

After  modelling  the  extended  Timed  CSP  processes  in  CLP(R),  the  prereq¬ 
uisite  is  to  check  feasibility  of  this  system  before  the  simulation  or  reasoning  or 
scheduling  of  this  system.  It  is  possible  that  there  is  a  conflict  among  its  where 
clause  and  its  sub  processes’s  where  clauses.  To  perform  this  task,  the  conjunc¬ 
tion  of  the  where  clauses  of  each  process  and  its  sub  processes  is  checked. 

Example  9.  We  plan  a  mission  which  is  to  fire  a  target.  It  contains  two  sub 
missions,  namely,  the  Supply  and  Fire ,  which  are  defined  as  follows. 

Supply  =  fetch  A  boxup  A  carry  -A-  unload  — >  SKIP 

Fire  =  load  A  aim  A  fire  — >  SKIP  where  fire. engage  —  load. engage  >  12 
Mission  =  Supply ;  Fire  where  Mission. end  —  Mission. start  <  10 

If  we  look  at  each  process  and  its  where  clause  separately,  they  are  all  feasible. 
Let’s  check  out  the  conjunction  of  these  clauses  in  CLP(R)  which  produces  a 
conjunction  of  a  set  of  constraints: 

Fire. start  ^  Fire . end  A 

Fire. start  ^  Fire. fire. engage  A 

Fire.  fire,  eng  age  ^  Fire,  end  A 

Fire. fire. engage  —  Fire. load. engage  >  12  A 

Fire. start  ^  Fire  .load. engage  A 

Fire  .load,  eng  AGE  ^  Fire,  end  A 

Mission. start  ^  Fire. start  A 

Fire. end  ^  Mission. end  A 

Mission. end  —  Mission. start  <  10 

The  conjunction  of  the  constraints  returns  false.  Therefore  this  Mission  process 
is  not  a  feasible  plan. 

5  Conclusion  and  Further  Work 

In  this  project,  we  proposed  a  new  timed  planning  formalism  to  model  timed 
military  plans  with  critical  timing  requirements.  This  new  timed  formalism  is 
an  extension  to  Timed  CSP  with  timed  planning  features.  The  extensions  (in 
where  clause)  are  easily  captured  semantically  in  CLP,  which  is  the  underlying 
reasoning  language  for  this  formalism.  In  this  project,  we  also  built  a  tool  to 
reason  and  analyze  this  new  formalism,  which  to  our  knowledge,  is  the  first 
mechanized  reasoning  support  for  Timed  CSP.  This  tool  uses  CLP  as  underlying 
reasoning  engine  and  is  implemented  in  JAVA. 

Our  further  work  will  include  the  enhencement  of  the  tool  to  handle  timed 
fairness  issues  and  other  advanced  real-time  concurrent  features.  If  it  is  possible, 
we  would  like  to  build  this  tool  as  plug-in  feature  in  existing  Millitary  planning 
tool  (esp.  Air  Campaign  Planning  Tools). 
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Appendix  A:  Operational  Semantics  of  Timed  CSP  in  CLP(R) 

Operational  Semantics  of  operations  of  Timed  CSP  defined  in  CLP(R),  where 
tau  indicates  the  internal  event  r,  and  E  is  an  arbitrary  event. 

tos(eventprefix(E ,  P),  T 1,  Q,  eventprefix(E ,  P),  T1  +  D)  :  —D  >  0. 
tos(eventprefix(E ,  P),  T,  [E],  P,  T). 
tos(prefixchoice(X ,  P),  T,  [Y],P,  T )  :  —  member  [Y  ,X). 
tos(prefixchoice(-,  P),  T 1,  [],  P,  T1  +  D)  :  —D  >  0. 

tos(timeout(Q  1, ,  ),  T,  [E],  P,  T )  :  —  tos(Ql,  T,  [E],  P,  T). 

tos(timeout()  Q2 ,  D),  T,  [tau],  Q2,  T )  :  —D  =  0. 
tos(timeout(Ql,  Q2,  D),  T,  [tau],  timeout(P ,  Q2,  D),  T ) 

:  —  tos(Q  1,  T,  [tau],  P,  T). 

tos (timeout (Ql,  Q2,  D),  Tl,  [],  timeout(P ,  Q2,  D  —  T),  T1  +  T) 

:  -  T  >  0,T  <=  D,  tos(Ql,  Tl,  [],  P,  T1  +  T). 
tos(wait(D),  T1,E,P,  T2 )  :  —tos (timeout {stop,  skip,  D),  T1,E,P,  T2). 
tos(extchoice(P  1,)  ,  T,  [E],  P3,  T )  :  —tos(P  1,  T,  [U],  P 3,  T ). 
tos(extchoice(tP2),  T,  [E],PA,  T )  :  —  tos(P2,  T,  [E],PA,  T). 
tos(extchoice(Pl,  P2),  T,  [tau],  extchoice(P3,  P2),  T)  :  —tos(P  1,  T,  [tau],  P3,  T) 
tos(extchoice(Pl,  P2),  T,  [tau],  extchoice(Pl,  PA),  T)  :  —tos(P2,  T,  [tau],  PA,  T) 
tos(extchoice(Pl,  P 2),  Tl,  [],  extchoice(P3,  PA),  T 2) 

:  —  T2  >  Tl,  tos{Pl,  Tl,  [],  P3,  T2),  tos{P2,  Tl,  [],  PA,  T2). 
tos(interleave{Pl ,  P2),  T,  E,  interleave(P3,  P2),  T) 

:  -tos{Pl,  T,  E,  P3,  T),  {E  ==  [];  E  ==  [tau]). 
tos(interleave(Pl ,  P2),  T,  E,  interleave(Pl,  PA),  T) 

:  —tos(P2,  T,  E,  PA,  T),  (E  ==  [];  E  te=  [tau]). 
tos(interleave(Pl,  P2),  T,  [E],  interleave(P3,  P2),  T)  :  —tos(P  1,  T,  [E],  P3,  T). 
tos(interleave(Pl,  P2),  T,  [E],  interleave(Pl,  P3),  T)  :  —tos(P2,  T,  [E],  P3,  T). 
tos(interleave(Pl,  P2),  Tl,  [],  interleave(P3,  PA),  Tl  +  D) 

:  —D  >  0,  tos{Pl,  Tl,  [],  P3,  Tl  +  D),  tos{P2,  Tl,  [],  PA,  Tl  +  D). 
tos(interleave(Pl,  P 2),  T,  [termination],  interleave{P3,  PA),  T) 

:  —  tos(Pl,  T,  [termination],  P3,  T),  tos(P2,  T,  [termination],  PA,  T). 
tos(hiding(P  1,X),  T,  [tau],  hiding (P2,  X),  T) 

:  —tos(Pl,  T,  [E],  T,  P2),  member(E,  X). 
tos(hiding(Pl,  X),  T,  [i£],  hiding(P2,  X),  T) 

:  —tos(Pl,  T,  [E],  P2,  T),  not(member(E ,  X)). 
tos(hiding(P  1,  X),  Tl,  [],  hiding(P2,  X),  Tl  +  D) 

:  —D  >  0,  tos(Pl,  Tl,  [],  P2,  Tl  +  D), 
not(member(A,  X),  tos(P  1,  [A] ,  _)). 

tos(sequential(Pl,  P2),  T,  [E],  sequential (P 3,  P2),  T) 

:  —tos(Pl,  T,  [E],  P3,  T),  not(E  =  termination) . 
tos(sequential(Pl,  P2),  T,  [termination],  P2,  T)  :  —tos(Pl,  T,  [termination], t  T) 
tos(sequential(Pl,  P2),  Tl,  [],  sequential(P3,  P2),  Tl  +  D) 

:  —D  >  0,  tos(P  1,  Tl,  [],  P3,  Tl  +  D),  not(tos(P  1,  [termination] , _)). 
tos(interrupt(Pl,  P2),  T,  [£],  interrupt(P3,  P2),  T)  :  —tos(P  1,  T,  [E],  P3,  T). 
tos(interrupt(-,  P2),  T,  [E],  P3,  T)  :  —tos(P2,  T,  [E],  P3,  T). 
tos(interrupt(Pl,  P2),  Tl,  [],  interrupt(P3,  PA),  Tl  +  D) 

:  -D  >  0,  tos(Pl,  Tl,  [],  P3,  Tl  +  D),  tos{P2,  Tl,  [],  PA,  Tl  +  D). 


